A storage system is a computer that provides storage service relating to the organization of information on writeable persistent storage devices, such as memories, tapes or disks. The storage system is commonly deployed within a storage area network (SAN) or a network attached storage (NAS) environment. When used within a NAS environment, the storage system may be embodied as a file server including a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on, e.g. the disks. Each “on-disk” file may be implemented as a set of data structures, e.g., disk blocks, configured to store information, such as the actual data for the file. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
The file server, or filer, may be further configured to operate according to a client/server model of information delivery to thereby allow many client systems (clients) to access shared resources, such as files, stored on the filer. Sharing of files is a hallmark of a NAS system, which is enabled because of semantic level access to files and file systems. Storage of information on a NAS system is typically deployed over a computer network comprising a geographically distributed collection of interconnected communication links, such as Ethernet, that allow clients to remotely access the information (files) stored on the file server. The clients typically communicate with the filer by exchanging discrete frames or packets of data according to pre-defined protocols, such as the well-known Transmission Control Protocol/Internet Protocol (TCP/IP).
In the client/server model, the client may comprise an application executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the well-known Internet. NAS systems generally utilize file-based access protocols; therefore, each client may request the services of the filer by issuing file system protocol messages (in the form of packets) to the file system over the network. By supporting a plurality of file system protocols, such as the conventional Common Internet File System (CIFS), the Network File System (NFS) and the Direct Access File System (DAFS) protocols, the utility of the filer may be enhanced for networking clients.
Conversely, a SAN is a high-speed network that enables establishment of direct connections between a storage system and its storage devices. The SAN may thus be viewed as an extension to a storage bus and, as such, a storage operating system of the storage system enables access to stored information using block-based access protocols over the “extended bus.” In this context, the extended bus is typically embodied as Fibre Channel (FC) or Ethernet media adapted to operate with block access protocols, such as Small Computer Systems Interface (SCSI) protocol encapsulation over FC (FCP) or TCP/IP/Ethernet (iSCSI). A SAN arrangement or deployment allows decoupling of storage from the storage system, such as an application server, and some level of storage sharing at the application server level. There are, however, environments wherein a SAN is dedicated to a single server.
It is advantageous for the services and data provided by a storage system such as a filer, to be available for access to the greatest degree possible. Accordingly, some computer storage systems provide a plurality of file servers (or filers) in a cluster, with a property that when a first filer fails, the second filer is available to take over and provide the services and the data otherwise provided by the first filer. When a first filer fails, the second filer in a cluster assumes the task of processing and handling any data access requests normally processed by the first filer. One such example of a cluster configuration is described in U.S. patent application Ser. No. 09/625,234 entitled NEGOTIATING TAKEOVER IN HIGH AVAILABILITY CLUSTER by Samuel M. Cramer, et al., the contents of which are hereby incorporated by reference.
In certain known file server cluster implementations, the transport medium is Ethernet cabling utilizing the TCP/IP protocol for transport of data. Various file service protocols can execute on top of the TCP/IP protocol, such CIFS or NFS. In known failover techniques involving clusters of filers, Network Interface Controllers (NIC) contain the capabilities to support multiple Media Access Control (MAC) addresses. When one of the file servers in a cluster detects a failure of its partner file server, for example, by sensing the partner file server is no longer emitting a heart beat signal, the surviving file server proceeds to take over the partner's disks. The surviving file server then executes a failover script, which involves obtaining the IP address of the failed file server and determining each MAC address associated with the failed file server. Each NIC on the surviving file server is then assigned a MAC address that was normally associated with a NIC of the failed file server. Thus, transfers with IP addresses which are mapped to a MAC address of the failed file server, are no longer routed to the failed file server, but instead are directed to the surviving partner file server.
However, in accordance with the iSCSI specification, each device attached to an iSCSI network requires an iSCSI name, which is unique within a given operating environment. Using conventional failover techniques, such as those described above, an iSCSI client will not properly failover to a surviving partner file server as the iSCSI name of the surviving partner file server will not be identical to that of the failed file server. As the surviving partner file server does not have the proper iSCSI name, clients of the failed file server will not have their data access requests properly routed to the surviving partner file server. In addition to the iSCSI name, the surviving file server must also have several other blocks of data for it to be able to transparently operate on the failed file server's behalf This additional data includes the LUN maps/masks associated with the failed filer for use during processing of data access requests and various types of iSCSI security information may include, for example, a list of which iSCSI initiators which may communicate with the failed target and what methods of authentication the target required. Instead, an error condition may occur as the iSCSI name or other information is not associated with the same device as the network address to which the client is directing data access requests.
It is thus an object of the present invention to provide a system and method for transport-level failover of iSCSI devices.